"""
@-*- coding: utf-8 -*-
@ python：python 3.8
@ 创建人员:ylx-lingxiao
@ 创建时间:2024/12/4  23:22
@ File:study11.py
@ Explanation:接口测试及自动化
"""
"""
1.接口分类，接口测试这里我们主要学习接口本身的功能测试，和接口自动化测试

接口是为不同系统和功能之间实现分离或连接的口，硬件接口和软件接口
硬件的比如说 USB接口 耳机接口
软件接口 常见的比如说api接口，也就是应用编程接口   application  program  interface

一个接口的交互过程
客户端通过网络来调用一个接口，通过接口和服务器交互，如一个URL带有对应的参数，发送到服务器，服务器和数据库交互后，服务端通过接口返回值给客户端



接口测试是测试系统组件之间接口的一种测试，主要用于检测系统内部，各个子系统之间，外部系统与子系统之间的交互，比如支付接口需要调用
如支付宝或者微信或者银行的外部接口
，测试的重点是要检查数据的交换，传输和控制管理过程，以及系统之间的相互逻辑依赖关系等


再通俗的来讲接口测试就是通过URL像服务器或者其它模块等，传输我们想传输的数据，然后看其返回是否是我们想要的
接口测试就是通过测试不同情况下的入参与之相对应的出参信息，来判断接口是否符合或者满足相应的功能性需求


B/S  浏览器和服务器架构    浏览器打开网站
C/S  客户端和服务器架构    
无论是上面哪种架构，都是需要前端和服务器进行交互，接口就是他们交互的枢纽


接口交互的过程；本质就是发送一个request 报文给服务器，服务器响应返回一个response 报文，我们对response报文进行分析
判断是否和我们的预期一致，从而验证业务是否正确实现



为什么要进行接口测试
1.越底层越早的发现bug，修复的成本是低的
2.前端随便变，接口测好了，后端不用变，业务逻辑有保证
3.检查系统的安全性，稳定性，前端的传参不可信，比如购物平台，前端会拦截-1，但是接口可以传入-1，从而检查后端是否做了相关措施
4.当前软件或系统的复杂度不断上升，进行接口测试可以在一定程度上提前介入测试，提升测试效率
5.接口测试比较容易实现自动化的持续集成，对比UI自动化，接口自动化是更加稳定的，减少人工回归测试的人力成本和时间，缩短测试周期
，支持后端快速发版
6.接口测试相对于UI来说更加的稳定，也可以说是一种特殊的单元测试，当一个系统提供了大量的后台服务，有较少或者基本没有页面操作，比较适合展开接口测试



前端的校验只是初步的页面校验，后台的逻辑校验才是重中之重
我们希望一个业务逻辑，前后端都校验，双重保证





怎么做接口测试
1.接口功能测试阶段
功能提测前期，指还没有页面或者前端开发还没完成时，后端开发逐步提供接口，持续提测
前后端联调后，业务时间紧张时，直接测试功能过程中，参杂着测试一下主要的接口，测试业务逻辑

1.接口功能测试过程
需求评审-整体的测试计划-开发结合需求文档出接口文档-接口文档评审达成一致-测试用例编写-执行接口测试-前后端联调-功能测试-交叉测试-系统测试-产品验收-输出测试报告-产品上线



接口包含哪些东西 http超文本传输协议     http接口测试必须掌握的知识点    接口一般用的就是http 或者https 协议
检查网页，network  xhr可以看到接口

requests URL           http(s)://host:port/path/parameters      http协议+IP或域名+port端口号+路径名称+？请求参数


header请求头描述相关信息  response header 服务器返回的数据类型 application json requests header 向服务器发送的数据类型  x-www-formed    application/json
form-data,开发怎么定义的，你就怎么实现

payload 展示相关的入参


method  请求方式  get/post常用  delete/put 不常用  开发怎么定义你怎么使用就行
get 请求会向数据库发索取数据的请求，直接获取数据，从而来获取信息，该请求就像数据库的select操作，只是用来查询数据，不会修改或者增加数据
不会影响资源内容，即刻请求，不会产生副作用，这种可以类似 url后面?可以直接跟条件参数，get一般用在查询，比如说，列表查询

post向服务器端发送数据，该请求会改变数据的种类等资源，像是数据库的insert  update  delete操作，会创建新内容，几乎目前所有的提交都是post请求

put 向服务端发送数据，从而改变信息，该请求类似数据库的update操作，用来修改数据的内容，其也可以做删除，就看开发怎么定义使用，我们测试不用太纠结

delete 用来删除某一个资源，请求就像数据库的delete操作

get  post区别
功能不同 get是从服务器上获取数据，post是像服务器传递数据
传送数据量不同  get传送的数据量小 不能大于2KB  post传送的数据量较大，一般被默认为不受限制
安全性不同  get安全性低  post安全性高





request parameters  请求参数，一种方式是url中后面的?后面传递参数  2.json格式{key,value}    3.from_data    开发怎么定义的你就怎么传


response status  响应状态码   200请求成功，和服务器连接成功    
302  呼叫转移，也就是重定向，比如你访问百度网络不好时会有中间页面，等待网络恢复后立马重定向至目标页面，也就是说如果访问会有中间页面，确认无问题后，再转移至目标页面
比如说你登录成功后，复制地址，退出登录后，继续访问复制的地址，应该重定向到登录页面，登录后退出再返回，应该还是重定向至登录页面，没登录不能进入

404 资源未获取到，服务器上无法找到相关的资源      500服务器错误
400 请求报文中存在语法错误


response 返回结果，json格式的数据，使用老师提供的工具 json handle 可以美观数据格式，也有可能返回结果是普通文本格式的


请求体中比较重要的是content_type，指的是你跟我请求的是什么类型的数据
实时通信就使用websocket通信
一般公司项目上线，都是用htpps协议的


http协议以明文的方式发送内容，不提供任何方式的数据加密，http不适合传输一些敏感信息
为了解决这一问题，可以使用另一协议 安全套接字层超文本传输协议 https 为了数据的安全，在http的基础上加了了ssl协议，ssl依靠证书来验证服务器的身份，为浏览器和服务器之间的通信加密
区别
https协议需要到ca申请证书，免费证书少，申请需要一定的费用
http是超文本传输协议，信息明文传输，https是具有安全性的ssl加密传输协议
http和HTTPS使用完全不同的连接方式，默认端口也不一样  前者80   后者443
http连接简单无状态，HTTPS是由ssl+http协议构建的可以进行加密传输，比http安全




接口测试用例编写
结合需求来完成
用例编号-用例名称-描述-接口地址-请求方式-前置条件-请求头部-请求参数-状态码-等级-期望响应结果-实际结果-备注
登录接口：
我们测接口是没有页面的，所以前置条件，数据库已存在登录账号
请求头部这里我们只写content_type application/x-www-form，去接口文档看就可以
请求参数  username:sang    password : 123


正向P0  一定是登录成功
后面的接口测试用例围绕写的
可以是 输入错误的，为空的，超长及特殊字符的
所以你的接口只需覆盖正常情况，颗粒度不需要太细

接口的自动化我们目标还是P0级别的用例

你在企业执行用例时，写你可以写的很细也可以对你熟悉的功能只写主要的，但是备注可以有很多边缘的测试点，提醒你测试的时候注意
你完成测试用例时也可以一次过好几条，但是这也是建立你熟悉用例和需求的基础上，而不用一条一条的对着过，比较低效率



cookie session  token
这些都是我们的鉴权方式

cookie
是一门客户端缓存技术
cookie的数据由服务器生成，发送给浏览器保存
cookie的数据格式是键值对
cookie数据的过期机制，设置过期时间

Ctrl shift delete 可以清除浏览器的缓存

这个cookie的缓存可以  比如说 登录记住用户名   记住用户的浏览记录
这个cookie 我们可以在application中 的cookie中去看   可以看到key  value  和这个值的过期时间
密码不能明文的存储在浏览器中

通过cookie 比如说你成功登录学之思后，只有你一个月，也就是有效期内不清楚cookie数据，那么你来访问网站的登录页面，都能看到回填的数据
cookie日常登录一个网站，今天选择记住输入用户名密码，登录回填的效果
第二天再次打开的情况下，就直接打开了，这时候用到的一个机制就是cookie

session
session是一门服务端会话缓存技术
session是由服务器端的web容器创建，保存可能在服务器端 redis 客户端的缓存，由开发决定
session保存数据也是用键值对的形式
session的过期时间，默认30分钟

session是服务端的会话技术，当用户登录了系统，服务器的web容器会创建一个会话，此会话可以保存登录用户的信息，以键值对的形式存储
，当用户登录完后才可以访问系统中的页面和数据、
比如说你直接访问某个项目的首页，你是无法访问的，会重定向到登录页面，登录后才可以访问
当你点击登录时，登录成功 ，服务端会创建一个session对话，保存登录的用户信息，并返回此会话的编号，login接口的响应头中会有一个set_cookie：session=’‘
此时浏览器会把session=’‘按照 key value的形式去存入到浏览器的cookie中去
这个session的会话编号是服务器返回的，服务器端的这个session会话保存了登录用的用户信息

登录成功后，后续去任何页面都可以，后面的每次请求都会带 浏览器cookie里边的这个session的值过去
都会带在 请求头中的cookie会带上你的session信息，带上后访问服务器时，服务器匹配上了就放行
登录成功后服务器返回给你session信息，把session信息存到cookie中去，后续请求通过携带浏览器中的session信息来和服务器中的session对话做鉴权即可
这个前提就是建立在服务端返回的session信息是存在客户端的
当服务器收到成功登录后的后续请求时，请求的cookie信息中由session信息，根据id去匹配对应的session对话，会话中有登录用户的信息
从而判断这个请求是一个用户发出去的，从而放行这个请求
当你的会话过期，你继续发起请求时，因为你从客户端带过期的会话编号还是之前的，所以验证不通过，提示你会话过期，重新登录


token 令牌
token是在客户端频繁的像服务器请求数据，服务器端频繁的去数据库查询用户名和密码进行比对，判断正确与否后，做出对应的提示，一般
手机端多用token，因为手机端没办法使用cookie或者session，比如说你使用iOS的手机打开app，这些app的加载可能不是浏览器，
打开app打开一个新闻，他不是像浏览器一样打开了一个页面
需要换一种方式来完成相关目的，我们使用token，但是浏览器端也是可以使用token的


token是服务器产生的一串字符串，以作为客户端请求的一个令牌，第一次登录成功后，服务器生成一个token，并且将这个token返回给
客户端，以后客户端只需要带上这个token来请求数据即可，无需带上用户名及密码，使用token的目的就是为了减少服务器端的压力
减少频繁的查询数据确认是否是正确的用户，增加服务器的健壮性
最简单的token就是 用户唯一身份标识uid+time+签名，可以防止第三方恶意拼接token请求服务器

一般登录接口的响应就会返回token值，后续的请求的请求头中都会带上token，去请求服务端


这些使用的鉴权方式由开发决定，具体由接口文档体现我们按接口文档去实现即可


区别对比 
cookie和session的区别
1.cookie存在客户端的浏览器上，session的数据放在服务器上
2.cookie不是很安全，比如说我们存储用户的不敏感数据时，如用户名，用户的个性化设置等，考虑安全请使用session，如存储密码，避免cookie欺诈
3.session会在一定的时间内保存在服务器上，当访问增多，会比较占用服务器的性能，考虑到减轻服务器的压力，使用cookie
4.单个cookie保存的数据不能超过4K，很多浏览器设置一个站点最多保存20个cookie
所以个人建议
登录信息存放在session中
其它信息需要保留的可以放在cookie中

token和session的区别
1.身份认证上 token比session的安全性高，浏览器端用session的情况多，手机端使用token的时候多
2.token和session都是为了身份验证，session是会话，token是令牌
3.session在服务器端会保留一份，可能保存在缓存 redis  文件   
4.session 和token都存在过期时间，需要管理过期时间




面试时会问-鉴权方式有哪些，都是什么，有什么区别


安装 json handle工具 美化json数据格式

怎么获取接口---web页面 检查  network  xhr 即可


比如说像我们一个查询全部文章/草稿箱/已读取的页面，接口出一个，因为文章都用的是一张表，通过不同的传参获取预期值即可
接口测试用例也就可以写一条，然后备注这几个参数即可



接口测试如何设计用例
一般考虑的入参形式的变化和接口的业务逻辑，一般也就是采取等价类 边界值 场景法居多
接口测试用例要考虑
正向用例，验证接口逻辑是否正确，根据业务逻辑输入参数，返回输出的值是否正常
异常用例
返回结果校验同数据库比对
接口测试中2个请求有严格的先后顺序，需要测试调转顺序的情况，比如说你要获取用户昵称，你就要先登录再获取，不能直接查询昵称







postman主要是做接口功能测试的
不同请求方式操作
content type x-www-form  方式选择body - x-www-form-unlencode 加入参数
content type form data  body form-data 主要上传，加入参数
content type application/json  body-raw-json(application/json) 加入参数

我们是使用 postman 的 collection  new collection 来创建当前版本或者可以理解为创建一个文件夹来存储相关模块或者版本的接口
创建完成后 add requests 即可或者右侧的+号
点击add requests 后 我们编辑这个接口的名称，然后就可以保存到这个项目中去了
然后看接口文档 确定 requests url  和请求的method  
看接口文档确认  content type的类型
如果是x-www-form 那你传参时，选择body   选择 x-www-form-unlencoded
有时你在body中选了后 header中会自动添加对应的有时候不会，这个你要确认下
然后你在body中传递你这个接口需要的入参即可，比如说 username    sang     password 123
点击send即可发起接口请求  下方的body中会显示响应结果

然后登录后，有一个查询昵称的接口，我们使用右侧的+来创建这个接口
创建成功后，在上一个接口执行后，执行这个可以成功，成功的原因可以是cookie中添加了jessionid信息
所以可以直接成功
再比如说你在查询昵称接口中的cookies 把这个删除了，那你也可以写在这个接口的header中去，request header

我们将第一个登录接口的cookies值   在第二个接口的书写形式为   key value      Cookie     JESSIONID=
也是可以的，是一样的，但是这个接口的cookies中不会主动添加使后面接口正常，这个目前仅仅对当前接口生效

对于这种session格式的，第一次登录成功后，相关信息都会存在cookies中，方便后续接口的鉴权使用，或者说只要你登录成功，在pastman
中这个，就会添加到你接口右上角的cookies中去，方便你后续接口的鉴权通过，可以不加到请求头中去

对于postman来说，登录成功后会主动的把 cookie : JESSIONID=  带到cookies中去，可以全局使用
后续这个集合的接口会引用cookies中的相关参数

对于get 请求的接口如果request url ？后面带的参数，postman 会主动将相关参数加入params


所以对于params 我们一般是写url后面带的参数的地方，headers中是请求头，比如说cookie  content type      body中是我们要传递的复杂数据结构等



对于新增文章接口的参数，按照接口文档去填写，根据对应参数来提示填写即可


如果你开启了下一个版本或者模块 那你可以再次新建一个collection 来管理


如果你是在功能提测前介入了接口测试，你需要根据接口测试文档或者需求来完成接口测试用例的书写



对于application/json 传参的，我们看接口时 可以直接 view resource  看入参的json格式



对于token 鉴权的请求，我们这样添加token，必须要自己在请求头中去添加即可，用请求头规定的数据格式即可
form data上传时 file参数填写后 选择file 可以直接在后面选择文件 即可

postman中全局变量添加后，使用{{变量名}} 来完成引用，右上角我们添加环境变量，不同项目使用不同的环境变量，对于像项目的url这种都可以方便的维护
这里对postamn还可以有动态取token的写的方式
以上就是postman的使用


下面是Charles 抓手机接口的工具
之前我们抓web的包通常都是检查页面然后抓包，但是对于手机，我们一般不能这样

http 正常抓

https 需要配置一下   proxy-ssl proxying settings  添加* 然后下方443端口即可

手机抓包查看配置文档，配置后 正常手机操作抓包即可


弱忘测试 结合Charles 小乌龟

"""